home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / scc / 9124 < prev    next >
Text File  |  1991-12-05  |  20KB  |  389 lines
  1. **************************************************************************
  2. Security Bulletin 9124                  DISA Defense Communications System
  3. 5 December 1991             Published by: DDN Security Coordination Center
  4.                                       (SCC@NIC.DDN.MIL)   1-(800) 365-3642
  5.  
  6.                         DEFENSE  DATA  NETWORK
  7.                           SECURITY  BULLETIN
  8.  
  9. The DDN  SECURITY BULLETIN is distributed  by the  DDN SCC  (Security
  10. Coordination Center) under DISA contract as  a means of  communicating
  11. information on network and host security exposures, fixes, &  concerns
  12. to security & management personnel at DDN facilities.  Back issues may
  13. be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.112.36.5]
  14. using login="anonymous" and password="guest".  The bulletin pathname is
  15. SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
  16. and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9124).
  17. **************************************************************************
  18.  
  19. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
  20. !                                                                       !
  21. !     The following important information was issued by the Computer    !
  22. !     Emergency Response Team (CERT)  and is being relayed unedited     !
  23. !     via the Defense Information Systems Agency's Security             !
  24. !     Coordination Center  distribution  system  as a  means  of        !
  25. !     providing  DDN subscribers with useful security information.      !
  26. !                                                                       !
  27. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
  28.  
  29. -------------------------------------------------------------------------------
  30.  
  31.  
  32.                     CERT/CC Generic Security Information
  33.  
  34. The following information is provided to sites that have, or may have,
  35. experienced a break-in.  Section A lists several ways to determine if a system
  36. has been compromised.  Sections B and C contain lists of vulnerabilities that
  37. have been exploited by intruders on UNIX and VMS systems respectively.
  38. Section D gives pointers to some tools that may be used to assist in securing
  39. your system.
  40.  
  41. The information in this document can be used to prevent several types of
  42. break-ins.  We encourage system administrators to review all sections of this
  43. document and modify their systems accordingly to close these potential
  44. vulnerabilities. 
  45.  
  46. -------------------------------------------------------------------------------
  47.  
  48. A.  How To Determine If Your System Has Been Compromised
  49.  
  50.     1.  Examine log files such as your 'last' log, process accounting, syslog,
  51.         and C2 security logs for logins from unusual locations or other unusual
  52.         activity.  Note that this is not foolproof; many intruders edit
  53.         accounting files in an attempt to hide their activity.
  54.  
  55.  
  56.     2.  Look everywhere on the system for unusual or hidden files (files that
  57.         start with a period and are normally not shown by ls) as these can be
  58.         used to hide information such as password cracking programs and
  59.         password files from other systems.  A favorite trick on UNIX systems
  60.         is to put a hidden directory in a user's account with an unusual name;
  61.         something like '...' or '..  ' (dot dot space space) or '..^G' (dot
  62.         dot control-G).  Also, files with names such as '.xx' and '.mail' have
  63.         been used.
  64.  
  65.  
  66.     3.  Look for set-uid files everywhere on your system.  Intruders often
  67.         leave set-uid copies of /bin/sh around to allow them root access at a
  68.         later time.  The UNIX find program can be used to hunt for setuid root
  69.         files.  The following example will find setuid root files on the '/'
  70.         (root) partition (Note:  The find command will not follow symbolic
  71.         links):
  72.  
  73.                   find / -user root -perm -4000 -print
  74.  
  75.  
  76.     4.  Check your system binaries to make sure that they haven't been changed.
  77.         We've seen intruders change programs on UNIX systems such as login,
  78.         su, telnet, and other critical network and system programs.  On VMS
  79.         systems, we've seen intruders change programs such as loginout.exe and
  80.         show.exe.  Compare the versions on your systems with known good copies
  81.         such as those from your initial installation tapes.  Be careful of
  82.         trusting backups; your backups could also contain Trojan horses.
  83.  
  84.  
  85.     5.  Examine all the files that are run by cron and at.  We've seen
  86.         intruders leave back doors in files run from cron or submitted to at.
  87.         These techniques can let an intruder back on the system even after
  88.         you've kicked him or her off.  Also, verify that all files/programs
  89.         referenced (directly or indirectly) by the cron and at jobs, and the
  90.         job files themselves, are not world-writable.
  91.  
  92.  
  93.     6.  Inspect /etc/inetd.conf for unauthorized additions or changes.  In
  94.         particular, hunt for entries that execute a shell program
  95.         (for example, /bin/sh or /bin/csh) and check all programs that are
  96.         specified in /etc/inetd.conf to verify that they are correct and
  97.         haven't been replaced by Trojan horses.
  98.  
  99.  
  100.     7.  Check your system and network configuration files for unauthorized
  101.         entries.  In particular, look for '+' (plus sign) entries and
  102.         inappropriate non-local host names in /etc/hosts.equiv, /etc/hosts.lpd,
  103.         and in all ~/.rhost files (especially ~root, ~uucp, ~ftp, and other
  104.         system accounts) on the system.  These files should not be
  105.         world-writable.  Furthermore, ensure that these files existed prior to
  106.         any intrusion and have not been created by the intruder.  
  107.  
  108.  
  109.     8.  Examine all machines on the local network when searching for signs of
  110.         intrusion.  In particular, check those hosts that share NIS (yellow
  111.         pages) or NFS mounted partitions, or that are referenced in
  112.         /etc/hosts.equiv files.  Also, check any hosts with which your users
  113.         share .rhost access.
  114.  
  115.  
  116.     9.  Examine the /etc/passwd file on the system and check for any
  117.         additional or modified accounts.  In particular, look for the
  118.         unauthorized creation of new accounts, accounts with no passwords, or
  119.         UID changes to existing accounts.
  120.  
  121.  
  122. B.  UNIX System Configuration Problems That Have Been Exploited
  123.  
  124.     1.  Weak passwords
  125.  
  126.         Intruders often use finger or ruser to discover account names and then
  127.         try simple passwords.  Encourage your users to choose passwords that
  128.         are difficult to guess (for example, words that are not contained in
  129.         any dictionary of words of any language; no proper nouns, including
  130.         names of "famous" real or fictitious characters; no acronyms that are
  131.         common to computer professionals; no simple variations of first or last
  132.         names.  Furthermore, inform your users not to leave any clear text
  133.         username/password information in files on any system. 
  134.  
  135.         A good heuristic for choosing a password is to choose an
  136.         easy-to-remember phrase, such as "By The Dawn's Early Light", and take
  137.         the first letters to form a password.  Insert in some punctuation or
  138.         mixed case letters as well.  For the phrase above, one example password
  139.         might be: bt}DeL{.  (DO NOT use this sample phrase for your password.)
  140.  
  141.         If intruders can get a password file, they will usually take it to
  142.         another machine and run password guessing programs on it.  These
  143.         programs involve large dictionary searches and run quickly even on
  144.         slow machines.  The experience of many sites is that most systems that
  145.         do not put any controls on the types of passwords used probably have
  146.         at least one password that can be easily guessed.
  147.  
  148.         If you believe that your password file may have been taken, change all
  149.         the passwords on the system.  At the very least, you should always
  150.         change all system passwords because an intruder may concentrate on
  151.         those and may be able to guess even a reasonably 'good' password.
  152.  
  153.         Section D details proactive steps that can be taken to ensure that
  154.         users set 'good' passwords and that encrypted passwords are not
  155.         visible to system users.
  156.  
  157.  
  158.     2.  Use of TFTP (Trivial File Transfer Protocol) to steal password 
  159.         files 
  160.  
  161.         To test your system for this vulnerability, connect to your system
  162.         using tftp and try 'get /etc/passwd'.  If you can do this, anyone else
  163.         on the network can probably get your password file.  To avoid this
  164.         problem, either disable tftpd if you don't require it or ensure that
  165.         it is configured with restricted access. 
  166.  
  167.         If you believe your password file may have been taken, the safest
  168.         course is to change all passwords in the system.
  169.  
  170.  
  171.     3.  Accounts without passwords or known passwords (accounts
  172.         with vendor-supplied default passwords are favorites) 
  173.  
  174.         Intruders often exploit system default passwords that have not been
  175.         changed since installation.  Be sure to change all default passwords
  176.         when the software is installed.  Also, be aware that product upgrades
  177.         can quietly change account passwords to a new default.  It is best to
  178.         change the passwords of default accounts after updates are applied.
  179.  
  180.         Scan your password file for extra UID 0 accounts, accounts with no
  181.         password, or new entries in the password file.  Do not allow any
  182.         accounts without passwords.  Remove entries for unused accounts from
  183.         the password file.  To disable an account, change the password field in
  184.         the /etc/passwd file to an asterisk '*', and change the login shell to
  185.         /bin/false to ensure that an intruder cannot login to the account from
  186.         a trusted system on the network.
  187.  
  188.  
  189.     4.  Holes in sendmail
  190.  
  191.         Make sure that you are running the latest sendmail from your vendor.
  192.         BSD 5.65 fixes all known holes.  To establish which version of
  193.         sendmail that you are running, use telnet to connect to the SMTP
  194.         port (25) on your system:
  195.  
  196.                     telnet <your hostname> 25
  197.  
  198.  
  199.     5.  Old versions of FTP;  misconfigured anonymous FTP
  200.  
  201.         Make sure that you are running the most recent version of ftpd, which
  202.         is the Berkeley version 5.60 of July 22, 1990.  Check with your vendor
  203.         for information on configuration upgrades.  Also check your anonymous
  204.         FTP configuration.  It is important to follow the instructions provided
  205.         with the operating system to properly configure the files and
  206.         directories available through anonymous FTP (for example, file and
  207.         directory permissions, ownership and group).  Note that you should
  208.         not use your system's standard password file or group file as the
  209.         password file or group file for FTP.  The anonymous FTP root directory
  210.         and its two subdirectories, etc and bin, should not be owned by ftp.
  211.  
  212.  
  213.     6.  Fingerd hole used by the Morris Internet worm
  214.  
  215.         Make sure that you're running a version of finger that is more recent
  216.         than November 1988.  Numerous Berkeley-derived versions of UNIX were
  217.         vulnerable.
  218.  
  219.  
  220.     7.  Inappropriate network configuration file entries
  221.  
  222.         Several vendors supply /etc/hosts.equiv files with a '+' (plus sign)
  223.         entry.  The '+' entry should be removed from this file because it means
  224.         that your system will trust all other systems.  Other files that
  225.         should not contain a '+' entry include /etc/hosts.lpd and all ~/.rhost
  226.         files on the system.  These files should not be world-writable.  We
  227.         recommend that you do not support the following services in your
  228.         /etc/inetd.conf file unless you specifically require them: 
  229.  
  230.                    port 11 - systat
  231.                    port 69 - tftp
  232.                    port 87 - link
  233.  
  234.  
  235.     8.  Misconfiguration of uucp
  236.  
  237.         If your machine supports uucp, check the L.cmds (Permissions) file and
  238.         ensure that only the commands you require are included. This file
  239.         should be owned by root (not by uucp!) and world-readable.  The L.sys
  240.         (Systems) file should be owned by uucp and protected (600) so that
  241.         only programs running setuid uucp can access it.
  242.  
  243.  
  244.     9.  Inappropriate 'secure' settings in /etc/ttys and /etc/ttytab
  245.  
  246.         Check the file /etc/ttys or /etc/ttytab depending on the release of
  247.         UNIX being used.  The default setting should be that no terminal lines,
  248.         pseudo terminals or network terminals are set secure except for the
  249.         console.
  250.  
  251.  
  252.    10.  Inappropriate entries in /usr/lib/aliases
  253.  
  254.         Examine the /usr/lib/aliases (mail alias) file for inappropriate
  255.         entries.  Some alias files include an alias named 'uudecode' or just
  256.         'decode'.  If this alias exists on your system, and you are not
  257.         explicitly using it, then it should be removed.
  258.  
  259.  
  260.    11.  Inappropriate file and directory protections
  261.  
  262.         Check your system documentation to establish the correct file and
  263.         directory protections and ownership for system files and directories.
  264.         In particular, check the '/' (root) and '/etc' directories, and all
  265.         system and network configuration files.  Examine file and directory
  266.         protections before and after installing software or running
  267.         verification utilities.  Such procedures can cause file and directory
  268.         protections to change.
  269.  
  270.  
  271.    12.  Old versions of system software
  272.  
  273.         Older versions of operating systems often have security
  274.         vulnerabilities that are well known to intruders.  To minimize your
  275.         vulnerability to attacks, keep the version of your operating system
  276.         up-to-date and apply security patches appropriate to your system(s) as
  277.         soon as they become available.
  278.  
  279.  
  280. C.  VMS System Vulnerabilities
  281.  
  282.     1.  Accounts with known default passwords
  283.  
  284.         Intruders often exploit system default passwords that have not been
  285.         changed since installation.  Make sure to change all default passwords
  286.         when the software is installed.  Be aware that product upgrades can
  287.         quietly change account passwords to a new default.  It is best to
  288.         change the passwords of default accounts after updates are applied.
  289.         Accounts no longer in use should be removed from the authorization
  290.         file and rights database.  Dormant accounts should be set to DISUSER.
  291.  
  292.         Intruders also try guessing simple user passwords.  See the discussion
  293.         on weak passwords in Section A for suggestions on choosing good
  294.         passwords.
  295.  
  296.  
  297.     2.  Unauthorized versions of system files
  298.  
  299.         If an intruder gets into a system, the programs patch.exe,
  300.         loginout.exe, and show.exe are often modified.  Compare these programs
  301.         with those found in your distribution media.
  302.  
  303.  
  304. D.  Software Tools To Assist In Securing Your System
  305.  
  306.  *****************************************************************************
  307.  *  The CERT/CC will not formally review, evaluate, or endorse the tools     *
  308.  *  and techniques described.  The decision to use the tools and             *
  309.  *  techniques described is the responsibility of each user or               *
  310.  *  organization, and we encourage each organization to thoroughly evaluate  *
  311.  *  new tools and techniques before installation or use.                     *
  312.  *****************************************************************************
  313.  
  314.     1.  Shadow passwords
  315.  
  316.         If your UNIX system has a shadow password capability, you should
  317.         consider using it.  Under a shadow password system the /etc/passwd
  318.         file does not have encrypted passwords in the password field.  Instead
  319.         the encrypted passwords are held in a shadow file that is not world
  320.         readable.  Consult your system manuals to determine whether a shadow
  321.         password capability is available on your system, and to get details of
  322.         how to set up and manage such a facility.
  323.  
  324.  
  325.     2.  COPS (The Computer Oracle and Password System)
  326.  
  327.         COPS is a publicly available collection of programs that attempt to
  328.         identify security problems in a UNIX system.  COPS does not attempt to
  329.         correct any discrepancies found; it simply produces a report of its
  330.         findings.  COPS was written by Dan Farmer and is available via
  331.         anonymous FTP from the cert.sei.cmu.edu system (192.88.209.5) in the
  332.         /pub/cops directory and via uucp from uunet.uu.net.
  333.  
  334.  
  335.     3.  passwd+
  336.  
  337.         passwd+ is a replacement program suite that allows a system
  338.         administrator to enforce policies for selecting passwords.  The suite
  339.         also provides a logging capability.  passwd+ was written by Matt
  340.         Bishop and can be obtained by anonymous FTP from the dartmouth.edu
  341.         system (129.170.16.4) in the file /pub/passwd+.tar.Z.  Please read the
  342.         README.IMPORTANT file which accompanies this software distribution.
  343.  
  344.  
  345.     4.  TCP/IP Wrapper Program
  346.  
  347.         This program provides additional network logging information and gives
  348.         a system administrator the ability to deny or allow access from certain
  349.         systems or domains to the host on which the program is installed.
  350.         Installation of this software does not require any modification to
  351.         existing network software or network configuration files.
  352.         The program was written by Wietse Venema from Eindhoven University of
  353.         Technology in the Netherlands and is available via anonymous FTP from
  354.         the cert.sei.cmu.edu system (192.88.209.5) in the file
  355.         /pub/network_tools/tcp_wrapper.shar. 
  356.  
  357.  
  358. -------------------------------------------------------------------------
  359.  
  360. If you believe that your system has been compromised, contact CERT/CC via
  361. telephone or e-mail.
  362.  
  363. Internet E-mail: cert@cert.sei.cmu.edu
  364. Telephone: 412-268-7090 24-hour hotline:
  365.  
  366.       CERT/CC personnel answer 7:30a.m. to 6:00p.m. EST(GMT-5)/EDT(GMT-4),
  367.       and are on call for emergencies during other hours.
  368.  
  369. Computer Emergency Response Team/Coordination Center (CERT/CC)
  370. Software Engineering Institute
  371. Carnegie Mellon University
  372. Pittsburgh, PA 15213-3890
  373.  
  374. --------------------------------------------------------------------------
  375.  
  376. **************************************************************************
  377. *                                                                        *
  378. *  Additionally, if you are a DDN user and you believe that your system  *
  379. *  has been compromised, you need to contact the DDN Security            *
  380. *  Coordination Center (SCC) via telephone or e-mail.                    *
  381. *                                                                        *
  382. *     E-mail address: SCC@NIC.DDN.MIL                                    *
  383. *     Telephone: 1-(800) 365-3642                                        *
  384. *                                                                        *
  385. *  NIC help desk personnel answer 7:00 a.m. to 7:00 p.m. EST(GMT-5)      *
  386. *  Monday through Friday except holidays.                                *
  387. *                                                                        *
  388. **************************************************************************
  389.